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Introduction 

In the teaching of mathematics, problem statements are often used to provide exercises which 
require the students to apply the knowledge learned. The student must read a P ar ^ ra Ph and 
determine first what the problem is, then apply the appropriate equation to find the answer. Sys 

development is analogous to solving math problem statements. There is the pn ablem s tate ™ nt 

(requirements) which must be understood so that the right equation (design) can be applied for the 
solution. 

If the study of mathematics emphasizes only the study of equations and how they are derived, the 
student will be ill-equipped to use that knowledge in practical applications. Similarly, des '9 n 
methods which do not have supporting methods for understanding requirements will prove difficult 

to use in practical system development. 

The use of objects in design methodologies has provided a mechanism whereby software engineers 
can take fuller advantage of software engineering principles. However these concept are jus 
beginning to reach their full potential as we move them earlier into the lifecycle. 

This paper presents an approach, developed at the U nisys Houston Operation Division which 
supports the early identification of objects. This "domain oriented analysis and development 
concept is based on entity relationship modeling and object data flow diagrams. Th * s ® 1 m ° de 1 9 
techniques, based on the GOOD methodology developed at the Goddard Space Flight Center [4], 
support the translation of requirements into objects which represent the real-world problem 
domain The goal is to establish a solid foundation of understanding before design begins, thereby 
giving greater assurance that the system will do what is desired by the customer. The transition > from 
requirements to object oriented design is also promoted by having requirements described m terms 

of objects. 

Presented is a five step process by which objects are identified from the requirements to create a 
problem definition model. This process involves establishing a base line requirements list from iwhic 
an object data flow diagram can be created. Entity-relationship modeling is used to facilitate the 
identification of objects from the requirements. 

The paper concludes with an example of how semantic modeling may be used to improve the entity- 
relationship model and a brief discussion on how this approach might be used in a large scale 
development effort. 
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1-0 Approach Overview 

Following the principles of software engineering promotes a more pragmatic approach for system 

development. It requires a change in the overall concepts of how systems are created as well as new 
analysis and design methodologies. 

1.1 Domain Oriented Development 

Fora design to be successful, there must be an understanding of the problem it is intended to solve 
AH too often problem definition is established in just enough detail to begin design and evolves as 
the design evolves. This can lead to unstructured systems which are hard to implement and 
expensive to maintain. To eliminate this problem software development can be divided into the 
problem and solution domains. The problem domain provides the foundation for all solution 
domain activities. A greater discipline is introduced into development giving greater assurance that 
the requirements (problem) are understood before a design (solution) is attempted. 

!£*?* included in the problem domain are requirements generation and requirements analysis 
Theenc I product of requirements analysis is a problem definition model. This model becomes the 
foundation for all solution domain activities. 

Activities included in the solution domain are preliminary design, detail design, code, and test The 
end product is a delivered system which conforms to requirements. 



1.2 The Mechanics of Requirements Analysis 


Requirement analysis isconcerned with establishing what a system is to do. This information must 
b^umentad 3 T m eai,ly under!<ood by all parties involved in development. The process for 
understanding a set of requirements requires an ordered set of steps which clarify original 
requirement statements and allow key information to be identified. 
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The remainder of this paper will show in detail an approach which is made up of the following steps. 

Step 1: Compilea notebook containing all requirement statements and information from 

other sources which might be pertinent to the problem. 

Step 2: Rewrite the information from the notebook into concisely stated sentences. This 

establishes a baseline requirements list (BRL). 

Step 3: Develop a static model of the problem from the BRL using entity relationship 

modeling. This model will facilitate the identification of objects. 

Step 4: Identify the objects and develop a dynamic model of the problem from the entity 

relationship model using an object data flow diagram (ODD). 

Step 5: Reorganize the BRL so that the statements are grouped by object. 



2.0 Step 1 : Compiling an Information Notebook 

Complete requirements information is essential in order to create the system the customer really 
wants. The purpose of step one is to gather all information which might have any possible bearing 
on what the system is to do. The actual process for this step will vary as to the sources of information 
available. For entirely new development projects, this is the initial step of requirements generation. 
Information must be compiled from many different sources. For enhancements to an existing 
system, this step is the identification and collection of requirements pertinent to the enhancements. 
Information sources would be the existing requirements document, design specifications, and 
interviews of current users and maintenance personnel. The end result is to have all the information 
available for design gathered in a single reference. 


D. Drew 
Unisys 
3 of 32 



A Practical Approach to Object Based Requirements Analysis 


This approach was developed for a project which had an existing requirements document. The 
document was old and the system had undergone several major revisions. The notebook contained 
pages from the requirements document, information from a system closely related to the one being 
redesigned, and notes given by experts in the application. The end result was a collection of all 
available requirements information which then served as a single reference for analysis and design. 

3.0 Step 2: Establishing a Baseline Requirements List 

The resultant notebook contains all the information needed to create a model of what the system is 
todo. However, there is no meaningful structure. It is very difficult to determine: if the information 
is complete, if there is information that is not needed, or how the pieces of information relate to 
each other. A good organization of requirements is necessary in order to facilitate the extraction of 
entities, relationships, and attributes from the requirements and to develop the dynamic problem 
domain definition. The Baseline Requirements List (BRL) provides this needed structure. Each 
statement in the notebook is rewritten in a traditional "X shall Y" format where "X" is a noun or 
noun phrase and Y is some action the noun will perform. Rewriting in this form will force a 
greater understanding of each requirement piece. Ambiguous statements and statements which 
have no impact on what the system is to do can be easily recognized. Having all requirements stated 
as cause and effect also provide a solid platform for system testing. 


ORGANIZE REQUIREMENTS INFORMATION 



BRL 


IS 


X SHALL V 
X SHALL Y 
X SHALL Y 


4.0 Step 3: Developing a Static Problem Definition Model 

A static model of the problem is the first component of the problem definition model. Its purpose is 
to give structure to the requirements information that will facilitate the identification of the 
dynamic properties of the system. A static model represents all the possible entities, with their 
attributes and relationships, described by the BRL. The development of a static model based on the 
requirements is an information representation problem. Therefore, it is reasonable to borrow 
modeling techniques from the DBMS world. Entity relationship modeling has been recommended 
by Mike Stark and Ed Seidewitz of the Goddard Space Flight Center [4] and Dr. Charles McKay of the 
University of Houston at Clear Lake [2] as an appropriate tool for the structuring of requirements 
information. 
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Issues of completeness in requirements can be addressed with this model. Incomplete requirements 
appear as dangling entities which have no relationships or as relationships without clearly defined 
entities. An entity without relationships may also indicate a requirement statement which does not 
belong to the problem. This type of inconsistency is identified and resolved m an iterative process of 
reviewing the requirement statements which make up the part of the entity-relationship model in 
question until all unusual model structures are resolved. 



4.1 Entity-relationship Modeling 

The approach promoted by this paper for entity-relationship modeling consists of the entity- 
relationship model creation phase, the entity dictionary, which provides entity definitions which will 
be used throughout the software lifecycle, and entity-relationship diagrams, which can be used to 
graphically depict portions of the entity dictionary. Object data-flow diagrams, which depict the 
dynamic problem definition are generated from the entity-relationship model and will be addressed 
in section 5.0. The remainder of this section presents in detail how an entity-relationship model is 
developed from the BRL. 

A common example, a subset of a student registration system, will be presented with most of the 
topics in this section and in section 5 in order to help in understanding the concepts. The example 
will have the following requirements: 

1 . The system shall provide the capability to enter and maintain information regarding students. 

2. The system shall provide the capability to enter and maintain information regarding the 
courses in which students are enrolled. 

3. Student information shall include the student's name, age, major and social security number. 

4. Course information shall include the course's name, department, room number, meeting time 
and days, name of the professor teaching the course, a list of students enrolled in the course, 
the number of students currently enrolled in the course and the maximum number of students 
allowed in the course. 
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5. A course shall be closed when the number of currently enrolled students reaches the 
maximum number of students allowed in the course. Otherwise, the course shall be 
considered open. 

6. Students shall be allowed to enroll in an open course. 

7. Students shall not be allowed to enroll in a closed course. 

8. The system shall accept registration requests containing the name of a student and the name 
of the course in which he/she wishes to enroll. 

9. Registration requests shall be processed in order to determine whether or not a student may 
enroll in the requested course. 

4.2 Entity-Relationship Model Creation 

The entity-relationship model creation phase consists of extracting entities, attributes and 
relat.onsh.ps from the requirements. During this phase, the requirements are assumed to be in the 
form of the BRL discussed in section 3.0. 

4.2.1 Entity Extraction 

Entities will appear as nouns in the requirement statements. Different types of noun phrases reveal 
different types of entities [3], Common nouns, such as "terminal", "student" or "message", name a 
class of entities. Mass nouns and units of measure, such as "water", "matter" or "fuel", name a 
quality, activity, quantity or substance of the same. Proper nouns and nouns of direct reference such 
class^ t6rminal Ge ° r9e ° r " Syntax error advisory message", name specific instances of an entity 


The requirements will not necessarily name all of the entities in the problem domain. Related 
entities may have to be found by looking through documentation, talking to people who have some 
expertise in the area, etc. For example, suppose that the problem domain consists of a bucket 
containing different types of fruit. The requirements may state that the job is to remove the apples 
and oranges from the bucket and place them in different piles. The entities in this problem domain 
as shown by the requirements, are the apples, oranges and the bucket. However, there are other 
kinds of fruit that have to be considered when removing the apples and oranges (i.e. they must be 
discarded). Those other fruits are part of the problem domain and therefore are entities in the 
problem domain. 

There is another case in which entities are not explicitly named in the requirements. Suppose that 
the requirements in the apples and oranges problem also state that someone is to be notified when 
a spoiled apple is found in the bucket. This new requirement introduces two new entities a spoiled 
apple and a notification that a spoiled apple has been found. There is a gap in the problem domain 
model between the spoiled apple and the notification of the spoiled apple This gap is filled by an 
entity that represents the event that is characterized by findi ng the spoiled apple. The event entity is 
related to the notification entity in that someone is to be notified in the event that a spoiled apple is 
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Entities are either internal or external. Internal entities have an existence only within the scope of 
the problem domain. External entities have an existence outside the scope of the problem domain. 
The concept of internal and external entities is easier to consider if the problem domain is thought of 
as a "black box." Internal entities cannot be seen outside of the box but external entities can be seen 
entering or leaving the box. 

In the student registration example, the requirements yield the following entities. 


From requirement 1 : Student 


From requirement 2: Course, Student 


From requirement 3: Student 

From requirement 4: Department, Professor, Course_Roster, Course 


From requirement 5: Course, Closed Course, Open Course, Student 

From requirement 6: Student, Open Course 

From requirement 7: Student, Closed_Cour$e 
From requirements: Registration_Request 

From requirement 9: Course, Registration Request, Student 

The Course Roster in requirement 4 is the list of students enrolled in a course. 

4.2.2 Attribute Extraction 

Attributes usually appear in the requirements as information concerning entities. The following 
attributes are named in the requirements: 


Student Name, Age, Major, SS_Number 

Course Name, Current_Size, Max_Size, Time, 

Days, Room Number, Professor_Name, Department_Name 

Professor Name 

Department Name 

Student Name, Course Name 


Student: 

Course: 

Professor: 

Department: 

Registration Request: 

4.2.3 Relationship Extraction 

Relationships appear in the requirements as associations between pairs of entities, entities and 
attributes or relationships and attributes. The student registration requirements show the following 
relationships: 


Requirement 2: 


Is Enrolled ln(1:m) 

between Student and Course. 
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Requirement 4: Includes (1 : 1)/ls_A_Part_Of (1:1) 

between Course and Course Roster; 

Incl udes ( 1 : m)/ls_A_Part_Of (m : 1 ) 
between Department and Course, Professor; 

* s A List Of ( 1 : m)/ls A Member Of(m:1) 

between Course__Roster ancT Student; - 
Teaches (1 : 1)/ls_Taught_By (1 : 1) 
between Professor and Course. 


Requirement 5: 


Requirements: 


Requirement 7: 


Requirement 9: 


Is A T ype_Of (1:1) 

between Closed Course and Course, 

between Open Course and Course; 

is An Instance Of (1:1) 

between Course aTd Open_Course or Closed_Course 

May Enroll ln(1:m) 

between Student and Open Course. 

May Not Enroll ln(1:m) 

between Student aTTd Closed Course. 

References (1:1)/ Is Referenced By (1 :m) 

between Registration_Request and Student, 
between Registration_Requestand Course. ’ 


4.3 Entity Dictionary 


containing a list of symbols with theirassociated^rt^my^na^ieTarKl values'^] 3 ' Z€ ^ propert T ' st 


The following is an example of entity entries in the student registration entity dictionary. 

Closed Course (Entity) 

Rqmt Numbers 5, 7 

Scope External 

is A Type Of Course 


Course (Entity) 
Attributes 


Course — Name, Department_Name, Room Number, Time, Days 

Professor Name, Current Size, Max Size - V ’ 

Rqmt_Numbers 2, 4, 5, 9 — — 

Scope External 

is Taught By Professor 

* s A Part Of Department 

ls _ An _J nstance _0f Open Course, Closed Course 
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Is Referenced_By Registration_Request 
Includes Course Roster 

Course_Roster (Entity) 

Rqmt Numbers 4 
Scopelrrternal 
Is A Pa rt__Of Course 
Is - A - List Of Student 

Department (Entity) 

Attributes Department_Name 

Rqmt Numbers 4 

Scope External 
Includes Course, Professor 

Open Course (Entity) 

“Rqmt Numbers 5, 6 
Scope External 
Is A_Type_Of Course 

Professor (Entity) 

Attributes Professor_Name 

Rqmt Numbers 4 

Scope External 

Teaches Course 

Is A Part Of Department 

Registration Request (Entity) 

Attributes Student Name, Course Name 

Rqmt Numbers 8, 9 

ScopeTnternal 
References Student, Course; 

Student (Entity) 

Attributes Student_Name, Age, Major, SS_Number 

Rqmt Numbers 1, 2, 3, 5, 6, 7, 9 

ScopeTxternal 

Is Enrolled_ln Course 

Is - A Member_Of Course_Roster 

Mly ""Enroll In Open Course 

May - Not Enroll_ln Closed_Course 
Is Referenced By Registration Request 

The entity dictionary can be extended to include attributes. The following is an example of some of 

the attribute entries in the student registration entity dictionary. 

Course Name (Attribute) 

is" An Attri bute_Of Cou rse 

Rqrnt_^N umbers 4, 8 
Domain String 

Days (Attribute) 

Is An Attribute Of Course 

Rqmt “Numbers 4 
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Domain Character 

Values M, T, W, R, F, MWF, TR, MW 

Student Age (Attribute) 

ls_An Attribute Of Student 

Rqmt Numbers 3 

Domain Integer 
Range 16. 100 

Time (Attribute) 

Is An Attri bute Of Cou rse 

Rqmt Numbers 4 

Domain Character 
Length 5 

Range 08:00. 19:00 


4.4 Entity-Relationship Diagrams 

Entity-relationship diagrams are used to graphically depict a part of the problem domain. Attempts 
were made to split the problem domain into parts by using a levelling technique in which the upper 
levels in the problem domain consist of "aggregate entities" with the actual problem domain 
entities at the lower levels. Unfortunately, there was not much progress in this endeavor and 
ere ore a single-level description of the problem domain was created. Since a diagram showing 
the entire problem domain would be cumbersome, it is better to use the entity dictionary as the 

greatei^laH^cati on^' f [4] ° n ^ entity ' relationshi P dia 9 rams bein 9 generated to map parts needing 


n the entity-relationship diagram, entities are represented by rectangles and relationships by 
diamond-shaped boxes [1 J. Attributes are listed next to the rectangle representing the entity The 
arrows indicate the direction of relationships. Adouble-h aded arrow indicates the 1m rrrlornrn 
mapping class. ' 

Entity-relafonship diagrams can be generated in order to graphically map the problem domain onto 
one or more requirements or to show the problem domain from the perspective of a particular 
entity. In the latter application, it is useful to state the "order" of the diagram. A first-order entity- 
relationship diagram shows the central entity (the entity from whose perspective the problem 
domain is being viewed) and its relationships to surrounding entities. A second-order diagram 
shows the central entity, its relationships to surrounding entities and the relationships of each of the 
surrounding entities to its surrounding entities. 

Sample entity-relationship diagrams for the student registration system are shown in appendix A. 

5.0 Step 4: Developing a Dynamic Problem Definition Model 

or«h? COn u an i COnd u d i nQ com P° nent of the problem definition model is the dynamic model of the 
problem. It is through this model that data flow and control, as described by the requirements is 
represented. An object data flow diagram (ODD) is used to model the dynamic properties of the 
pro em [ ]. n DD is very similar to a data flow diagram from Yourdon structured analysis 
ec mques. The chief difference lies in what the bubbles represent. For an ODD the bubbles are 
objects. Since data is encapsulated in objects, there will not be any data stores. 
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The remainder of this section will present in detail how an ODD is derived from an entity- 
relationship model. 



5.1 Identifying Problem Domain Objects 

An object is a unique instance of an abstract data type which is a set of data and operations 

associated with that data. In order to identify the objects in the problem domain, first find all of the 
major abstract data types apparent in the problem domain and use an object to manage each one. 

The abstract data types are represented by entities that do not have an Is A Type Of, 

Is An Instance Of, Is A List Of or ls_A_Set_Of relationship to another entity. These 

entitiesare at theTighest level of abstraction for entities of a particular type. In the student 
registration problem, those entitiesare Course, Department, Professor, Registration_Request and 
Student. Each one of these entity classes will have an object to manage it. These candidate objects 
are Course Folder, Department_Folder, Professor_Folder, Registration and Student_Folder 

The next step is to find all entity classes associated through the Is A_Type_Of, ls_A_List_Of or 

Is A Set Of relationship with the entity classes found in the first step. In the example, 

Open - Course and Closed Course are associated with Course through the ls_A Type_Of 
relationship and Course_Roster is associated with Student via the ls_A_List_Ot relationship. The 
following objects and associated entities can be identified thus far: 


Course Folder: 

Department Folder: 

Professor Folder: 

Registration: 

Student Folder: 


Course, Open_Course, Closed_Course 

Department 

Professor 

Registration Request 

Student, Course Roster 
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The entity classes listed for each object represent the abstract data types provided by that object. At 
this point, it is possible to determine the set of requirements satisfied by each object. This is done by 
consulting the entity dictionary and finding the requirement statement numbers for each of the 
entities associated with each object. Applying this process to the five objects in the student 
registration system shows the requirements satisfied by each object: 

Cour$e_Folder: Requirements 2, 4, 5, 6, 7 and 9 


Department Folder: 
Professor Folder: 
Registration: 

Student Folder: 


Requirement 4 
Requirement 4 
Requirements 8 and 9 
Requirements 1, 2, 3, 4, 5, 6, 7 and 9 


The requirement sets for each object are not disjoint. The shared requirements (numbers 2 4 5 6 7 

and 9 in our example) describe the relationships between entities of different types. These 

relationships, in turn, describe the interfaces between different objects. 


n order to complete the definition of the problem domain objects, find all relationships between 
en ities of different types and add each member of the corresponding entity pairs to the appropriate 

object. For example, because of the relationship "Student Is Enrolled InCourse" thereisan 
interaction between the Student_Folder and Course_Folder objects. To show this interaction, add 
the entity Student to the Course_Folder object and Course to Student Folder. One exception to 
this procedure occurs when one member of the entity pair is a generaliTed entity class. An example 
of this is the relationship Student May_Enroll_ln Open Course". Since "Open Course 
*— , t — Ty ^-r?, f C ° urse ' add Course to Student FolderTnstead of Open Course. This procedure 

results in the following set of objects and associated entities: — 


Course Folder: 


Department Folder: 


Course, Open Course, Closed Course, Course Roster, Student, 

Department, Professor, Registration Request — 

Department, Course, Professor 


Professor_Folder: Professor, Department, Course 


Registration: 


Registration Request, Student, CourseStudent, Course Roster, 

Course, Registration Request ~ 


Having identified the problem domain objects and their associated 
diagram can be generated. 


entities, an object data-flow 


5.2 Generating Object Data-Flow Diagrams 

Generating an object data-flow diagram based on a set of problem domain objects is simply a matter 
of finding entities common to pairs of objects. For example, the entities that Course Folder and 
Student — Folder have in common are Student, Course Roster and Course. Those common entities 
represent interfaces between Course_Folder and StuJint Folder. On the object data-flow 

8r u r ®P resented b V drawing a line bitween the two rectangles representing 
the objects and labeling the line with the names of the common entities. The object data-flow 
diagram representing the objects from section 5. 1 is in Appendix B. 
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The problem domain objects identified can be formally documented (in terms of the entities used 
and produced) by adding them to the entity dictionary: 

Course Folder (Object) 

Rqmt Numbers 2, 4, 5, 6, 7, 9 

Uses Department, Course Roster, Student, Registration Request, Professor 

Produces Course 

Department Folder (Object) 

Rqmt Numbers 4 
Uses Professor, Course 
Produces Department 

Professor Folder (Object) 

Rqmt Numbers 4 
Uses Dipartment, Course 
Produces Professor 

Registration (Object) 

Rqmt Numbers 8, 9 
Uses Student, Course 
Produces Registration Request 

Student Folder (Object) 

Rqmt Numbers 1, 2, 3, 4, 5, 6, 7, 9 

Uses Course, Registration Request 

Produces Student, Course Roster 

5.3 Object Names 

The names given to objects play a key role in the development and understanding of the ODD. 
Naming objects is possibly the most difficult task in requirements analysis. The objects supply the 
framework for the representation of information and the eventual design. Therefore, their names 
must convey a concise meaning of the abstraction. 

Object names are always nouns or noun phrases. This facilitates using the objects as a structure 
which can be used to explain action. It should be obvious from the name what real world object is 
represented. It is very difficult if not impossible to pick object names which do not bias design 
toward a particular direction. Therefore, this fact must be understood and preconceived notions 
must be addressed when a name is chosen. The name must be broad enough to encompass all the 
details associated with an object. Operations found within an object should not contradict the 
implied meaning of the object's name. 

6.0 Step 5: Reorganization of the BRL 

The entity-relationship model and ODD provide a complete problem definition model. Furthermore, 
the ODD serves as a platform to launch into an object oriented design. The last step for the problem 
domain segment of development is to go back and group the statements in the BRL under headings 
which represent the objects they support. 
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The objects are the main organizational structure for the system. Re-grouping the requirements will 
help the designers to find the additional detail needed to continue development. It will help the 
testers create test procedures aligned along object boundaries. It will simplify the traceability of 
requirements to design for the designer, tester, and maintainer. In short, having the requirements 
document reflect the structure of the emerging design will provide a high level of continuity 
throughout the system's lifecycle. 

7.0 Enhancements to Problem Definition Modeling 

Requirements analysis is a specific application of an information representation problem. As current 
modeling techniques evolve, it is reasonable to expect improvements in the approach taken in 
problem definition modeling. Semantic data models are currently being introduced for use in 
modeling data bases. They provide a richer medium for the representation of information. This 
section describes how semantic modeling can be used to enhance the entity relationship model. 

Semantic data models allow designers to represent the entities of interest in an application in a way 
that more closely resembles the view the user has of these entities [6]. Semantic data models provide 
abstraction constructs that can be used to capture some of the meaning of the user application. 

The semantic entity-relationship model introduced in this section features the abstraction constructs 
provided by the semantic and hyper-semantic [6] data models and allows the analyst to further 
define the problem by stating the meaning of relationships between entities in the problem domain. 

7.1 Modeling Primitives 

Modeling primitives are atomic relationships whose meanings cannot be defined as a composition of 
other meanings. They form the basis on which other relationships can be defined. Modeling 
primitives can be grouped into relationship classes which correspond to the abstraction constructs of 
the hyper-semantic data model. The modeling constructs of the hyper-semantic data model and 
their associated relationship names include [6] 

Generalization: Similar entities are abstracted into a higher level entity-class. Relationship: 

Is A Type Of. 

Classification: Specific instances are considered as a higher level entity-class. Relationship: 

Is An Instance Of. 

Aggregation: An entity is related to the components that make it up. Relationship: 

Includes/ ls_A Part Of. 

Set Membership: Several entities are considered as a higher level set entity-class. Relationships: 
Is A Set Of /Is A Member Of. 

List Membership: Several entities are considered as a higher level list entity-class. 

Relationships: ls_A_List_Of/ Is A Member Of. 

Constraint: A restriction is placed on some aspect of an entity or relationship. Relationship: 

Is A Constraint On. 
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Heuristic: An information derivation mechanism is attached. Relationship: 

Is A Heuristic On. 

Synchronous Temporal: Specific entities are related by synchronous characteristics and 

considered as a higher-level entity-class. Relationships: Is A Predecessor Of/ 

Is A Successor Of. 

Asynchronous Temporal : Specific entities are related by asynchronous characteristics and 
considered as a higher-level entity-class. Relationships: Initiates / Is Initiated By. 

Equivalence: Specific instances of an entity-class are asserted to be equivalent. Relationships: 

Is Equivalent To. 

The slash within the relationship names indicates two oppositely-directed relationships. 

7.2 Semantic Relationship Definition 

The semantic entity-relationship model provides a construct that allows the analyst to define the 
meaning of a relationship. This construct can be used to define a relationship in terms of other 
relationships and modeling primitives and to define the restriction class of a relationship. 

A relationship between entity classes A and B is restricted if instances of type A may only be related 
to certain instances of type 8 based on a condition. The relationship is existence restricted if 
instances of type A may only to be related to those instances of type B for which they depend on 
their existence [7]. 

In order to walk through a short example of a relationship definition, consider the Is Enrolled In 

relationship between Student and Course. The objective is to state what is meant by"the phrase, "a 
student is enrolled in a course ." The course roster may be used in order to determine if a particular 
student is enrolled in a particular course. Remember from section 4.2 that a course roster is a list of 
students enrolled in a course. Therefore, a student is enrolled in a course if the student is on the 
course roster. The relationship is written in the following form using the semantic relationship 
definition construct: 

entity class Course, Student, Course Roster; 

relationship Is Enrolled In (entity instance, entity instance); 

Student Is Enrolled In Course if 

CR Is An Instance Of Course Roster and 

Course Includes CR and 
Student Is A Member OfCR; 

The relationship statement declares Is Enrolled In as a relationship between two entity instances. 
Therefore, the definition of the Is EnTolled InTelationship between Student and Course is 
concerned with an instance of Student and aTTinstance of Course. 
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The first clause within the relationship definition, "CR Is An Instance OfCourse Roster", 
defines an entity CR which is an instance of entity class Course Roster. The second clause, "Course 
Includes CR", associates CR with the particular instance of Course with which the relationship is 
invoked. The third clause states that the instance of Student with which the relationship is invoked 
must be a member of the course roster CR in order for the Is Enrolled In relationship to be 
satisfied. 

The relationship is invoked by replacing Student and Course with appropriate instances, for example 
"George Is Enrolled In Physics". In this invocation of the relationship, CR is the course roster for 
Physics and the relationship is satisfied if George is on that roster. 

The semantic relationship definition construct can be thought of as "infix Prolog". In fact, it is rather 
easy to convert the above example into Prolog: 

is enrolled in (Student, Course):- 

is an instance of (CR, Course Roster), 

includes (Course, CR), ~ 

is a member of (Student, CR). 

If one could "code" the modeling primitives in Prolog and generate the appropriate Prolog 
declarations, it would be possible to execute a problem domain model. This may be useful in 
ensuring that the problem domain model is correct before going on to create objects and initiate 
design. This process is analogous to executing a design before implementation. 

8.0 Considerations For Large Projects 

This paper is based on a small project projected to be only 10,000 lines of code. An important 
question to ask is, "How will this approach support the development of a large system of 500,000 
lines or greater?" 

The basic approach is good for any size project. What complicates larger systems is the large number 
of requirements to be considered. It may not be practical or even possible to examine all the 
requirements at the same time as was done for this project. 

To resolve this problem, approach the requirements as layers of abstraction. Read through the 
document and extract those statements which define a very high level view of the system. Apply the 
approach presented in this paper to produce a problem definition model for this high level 
abstraction. Now begin an iterative process of stripping off layers of detail for each object identified 
in the previous level of abstraction and create a problem definition model. Use the approach 
presented in this paper for each iteration. 

As each layer of abstraction is added to the model, check the preceding layer to assure that the 
objects and interfaces already established still hold true. If there are inconsistencies, make the 
necessary adjustments and continue with the process. 
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Summary 

Students who spend all their time understanding math equations without applying them to problem 
statements will be ill-equipped to solve real world problems. System developers who possess the 
latest techniques in system design but have inadequate approaches to requirements analysis are 
destined to create wonderful designs which solve the wrong problem. The approach in this paper is 
a beginning to the application of modern analysis techniques rooted in the theoretical foundation 
of software engineering. A pragmatic approach allows for better conformance to those 

requirements in design. A model based on objects permits closer adherence to software 

engineering principles earlier in the lifecycle. It is not always easy to see objects m the requirements 
Use of the entity-relationship model eases this problem by structuring the information in a form 
more conducive to object recognition. 
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Appendix A. Sample Entity_Relationship Diagrams 


E-R DIAGRAM FOR STUDENT REGISTRATION REQUIREMENT 4 
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First order diagram for entity Student 
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Second order diagram for entity Student 
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Appendix B. Sample Object Data-Flow Diagram 

Object data-flow diagram for student registration system 
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